![]() |
|||
![]()
|
![]() |
![]() Click Here! |
![]() |
INTEGRATING HETEROGENEOUS DATA BASE SYSTEMS Migrating legacy data bases to new generation architectures is difficult. Although it is desirable to migrate such data bases and applications to client/server architectures, the costs involved in many cases are enormous. Therefore, the alternative approach is to keep the legacy data bases and applications and develop mechanisms to integrate them with new systems. The distributed object management system approach in general, and the CORBA approach in particular, are examples of such mechanisms. Although the major advantage of the CORBA approach is the ability to encapsulate legacy data base systems and data bases as objects without having to make any major modifications, techniques for handling the various types of heterogeneity are still necessary (see Exhibit 6-6-3). The CORBA approach does not handle problems such as transaction heterogeneity and semantic heterogeneity. However, the procedures used to handle the types of heterogeneity can be encapsulated in the CORBA environment and invoked appropriately.
Handling Client Communications with the Server A client will need to communicate with the data base servers, as shown in Exhibit 6-6-4. One method is to encapsulate the data base servers as objects. The clients can issue appropriate requests and access the servers through an ORB. If the servers are SQL-based, then the entire SQL query/update request could be embedded in the message. When the method associated with the server object gets the message, it can extract the SQL request and pass it to the server. The results from the server objects are then encoded as a message and passed back to the client through the ORB. This approach is illustrated in Exhibit 6-6-5.
Handling Heterogeneity Different types of heterogeneity must be handled different ways. For example, if the client is SQL-based and the server is a legacy data base system based on the network model, then the SQL query by the client must be transformed into a language understood by the server. One representation scheme must be transformed into another. The clients request must first be sent to the module that is responsible for performing the transformations. This modulethe transformercould be encapsulated as an object. As illustrated in Exhibit 6-6-6, the clients SQL request is sent to the transformer, which transforms the request into a request understood by the server. The transformed request is then sent to the server object. The transformer could directly transform the SQL representation into a network representation, or it could use an intermediate representation to carry out the transformation.
The distributed processor could also be used to perform distributed data management functions. The distributed processor is responsible for handling functions such as global query optimization and global transaction management. This module is also encapsulated as an object and handles the global requests and responses. The response assembled by the server is also sent to the transformer to transform into a representation understood by the client. Response delivery is illustrated in Exhibit 6-6-7.
Semantic Heterogeneity If semantic heterogeneity has to be handled, then a repository should be maintained to store the different names given to a single object or the different objects represented by a single name. The repository could be encapsulated as an object that would resolve semantic heterogeneity. For example, a client could request that an object be retrieved from multiple servers. The request is first sent to the repository, which issues multiple requests to the appropriate servers depending on the names used to denote the object. This approach is illustrated in Exhibit 6-6-8. The response may also be sent to the repository so that it can be presented to the client in an appropriate manner. The repository could be an extension of the transformer illustrated in Exhibit 6-6-6. All the communications are carried out through the ORB.
SUMMARY The CORBA approach is an excellent means of addressing heterogeneityespecially with respect to queries, languages, transactions, schemas, constraints, and semantics. However, although CORBA is useful for integrating heterogeneous data base systems, there are still several issues that need further consideration. For example, should a server be encapsulated as an object? How can data bases be encapsulated? Should an entire data base be encapsulated as an object or should it consist of multiple objects? Should stored procedures be encapsulated also? Although there is still much work to be done, the various approaches proposed to handle these issues show a lot of promise. Furthermore, until efficient approaches are developed to migrate the legacy data bases and applications to client/server based architectures, approaches like CORBA and other distributed object management systems for integrating heterogeneous data bases and systems are needed.
|
![]() |
|
Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details. |